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Svas  rating  the  conversion  of  data 


'Th 1 a  report  deacribea  the  feasibility  o 
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eouired  and  computer  pcn»er  available.^ 
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The  material  presented  herein  represents  a  low  budget 
attempt  to  determine  the  feasibility  of  generating  input  to  the 
radar  scene  generation  software  in  the  field.  No  claims  are  made 
as  to  completeness  or  accuracy  of  detail,  however,  it  is  believed 
that  the  figures  as  stated  herein  arc  accurate  enough  to  Insure 
that  the  results  will  he  dependable. 

The  program  manager  for  Autometric  was  Dr.  Clifford 
W.  Greve.  The  Contracting  Officers  Technical  Representative  for 
ETl.  was  Cpt .  Ron  Magee. 
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INTRODUCTION 


This  report  will  describe  efforts  undertaken  by  Autometric, 

Inc.  to  determine  the  feasibility  of  performing  the  conversion  of  data 
from  a  field  deployable  data  base  to  input  data  for  a  radar  scene 
generation  algorithm  In  the  field  within  a  less-than-ten-minute  time 
frame.  The  method  described  below  is  not  purported  to  be  the  only  method, 
or  even  in  any  sense  an  optimal  method.  It  is  merely  one  which  would 
work  within  the  time  allotted,  and  fulfills  other  criterion  such  as  amount 
of  disc  storage  required,  and  computer  power  available. 

Estimates  of  computer  time  requirements  Include,  in  most 
cases,  the  fetch  times  as  well  as  the  actual  operation  times.  It  is  assumed 
that  the  FORTRAN  software  will  be  written  in  such  a  manner  that  reasonably 
efficient  code  will  be  generated,  and  that  such  things  as  manual  Indexing 
through  matrices  rather  than  using  the  standard  FORTRAN  double  subscripting 
methods  will  be  used.  The  areas  in  which  great  care  must  be  taken  to 
prevent  the  generation  of  Inefficient  code  by  the  FORTRAN  compiler  will  be 
Indicated  where  they  occur. 

In  order  to  address  processing  speeds,  one  must  make  some 
assumptions  as  to  the  equipment  which  will  be  used.  Therefore,  an 
equipment  conf igurat ion  has  been  selected  for  this  study.  Tills  selection 
in  no  wav  implies  selection  by  the  government  of  this  particular  configurati 
for  the  final  system. 

Given  these  conditions,  the  discussion  of  the  process  can  begin 

Assumed  Hardware  Configuration 

It  is  assumed  that  the  hardware  configuration  available  will 
be  as  follows.  The  central  computer  will  consist  of  a  Norden  PDP11/70 
with  enough  random  access  memory  to  support  a  thirty-two  thousand  word 
user  partition  in  addition  to  the  system  and  double  buffers  which  will 


be  outlined  below.  Basically,  this  requirement  translates  to  4 2K  words 
plus  the  system  requirements.  It  is  assumed  that  the  system  will  have 
hardware  floating  point  and  direct  memory  access  1/0  capability,  as  well 
as  a  memory  mapping  capability.  (All  the  above  with  the  exception  of 
hardware  floating  point  are  standard  on  the  PDP11/70).  The  disk  drives 
are  assumed  to  be  CDC  640  mil  spec  drives,  with  80  megabyte  total  capacity. 
For  timing  purposes.  It  Is  assumed  that  the  standard  NTDS  Interface  Is 
being  used,  although  we  understand  that  a  much  faster  interface  Is  available 
for  this  drive.  It  is  assumed  that  there  will  be  two  drives  available,  one 
for  the  use  of  the  P-Il  field  deployable  data  base,  and  one  for  use  in 
program  storage  and  swapping,  and  for  the  storage  of  Intermediate  and  final 
generated  data.  Thus  the  P-II  deployable  data  base  discs  will  never  be 
written  on,  thereby  minimizing  the  probability  of  damaging  the  data  base. 

Assumed  Processing  P rocedur e 

Because  much  of  the  information  involving  the  actual  scene 
generation  procedure  is  proprietary  to  various  vendors,  some  assumptions 
were  required  as  to  the  format  of  the  input  to  the  final  scene  generation 
software.  These  assumptions  were  furnished  to  Autometric  by  ET1.  cognizant 
personnel,  and  constitute  the  best  estimates  available  at  this  time  of  the 
required  outputs. 

The  process  basically  consists  of  using  a  field  deployable 
data  base  of  topographic  and  planimet rlc  information  to  generate  radial 
format  data  which  ran  be  used  for  the  generation  of  four  scene  to  be  used 
at  various  altitudes.  The  diameter  of  these  four  scenes  is  respectively 
71,  35.5,  19.75  and  8.875  kilometers.  Because  the  requirement  for  resolution 
increases  as  the  altitude  diminishes,  the  lower  scene  must  have  higher 
resolution,  and  therefore  all  scenes  are  considered  to  have  the  same  number 
of  picture  elements  per  rAdlal  scan,  and  the  same  number  of  radial  scans. 

It  is  assumed  that  there  are  500  sweep  line  with  120  elts  each.  It  has  been 
indicated  that  the  smallest  unit  of  resolution  being  used  currently  in  the 
scene  generation  is  on  the  order  of  fifty  meters.  Therefore,  we  will  assume 
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that  ti>«.  resolution  of  the  field  deployable  data  base  will  be  approximately 
fifty  meters. 


The  assumption  was  made  that  the  field  deployable  data  base 
could  be  in  essentially  any  format  which  was  required,  limited  only  by 
the  number  of  disc  packs  required  to  contain  it,  and  the  fact  that  only 
a  single  drive  was  available.  Considerations  of  processing  to  go  from 
the  standard  DLMS  planlmetric  and  topographic  data  to  the  P-11  deployable 
data  base  were  not  taken  into  consideration.  These  processes  go  on  in 
non-real-time  in  a  base  plant  environment,  and  therefore  must  be  considered 
to  be  of  lower  priority,  with  much  higher  time  allowances,  than  the  real 
time  processing. 

Civen  these  considerations,  then,  the  discussion  of  the 
individual  phases  of  the  problem  can  proceed. 

Definition  of  the  P-11  Field  Deployable  Data  Base 

Before  the  data  base  format  is  defined,  a  discussion  of 
pertinent  requirements  would  be  in  order.  First  of  all,  the  reasons  which 
will  be  seen  later  involving  buffer  sires  and  data  processing,  the  sire  of 
a  unit  in  the  data  base  should  be  approximately  71  by  71  kilometers,  or 
possible  Just  slightly  larger.  This  assures  that  any  single  target  can 
be  covered  by  at  most  four  portions  of  the  data  base,  and  that  the  amount 
of  data  to  be  read  and  processed  will  Include  a  minimal  amount  of  non-useable 
data.  A  smaller  sire  for  the  unit  of  storage  would  admit  the  possibility 
that  a  single  target  might  require  nine  or  more  units  to  cover  it,  while  a 
larger  size  unit  still  could  not  avoid  the  possibility  of  having  to  use 
four  units,  but  would  require  processing  considerably  more  data. 

Thus  it  is  seen  that  the  optimum  sire  for  a  single  unit, 
hereafter  called  a  geounit,  would  be  71  by  71  kilometers.  The  next  problem 
is  to  determine  the  coordinate  system  in  which  these  geounlts  should  be 
stored . 


For  purposes  of  insuring  continuity  of  the  coordinates 
throughout  the  area  of  interest,  it  is  mandatory  that  all  geounits 
be  placed  on  one  common  system.  It  would  be  possible  to  use  a  single 
map  projection  for  the  entire  4  million  square  kilometer  area,  but  the 
distortions  at  the  outside  edges  would  become  enormous.  The  one  system 
which  is  consistent  over  all  of  the  European  continent,  and  which  is 
easily  convertible  to  a  local  tangent  system  (the  system  which  is  used  for 
the  final  generation)  is  the  geographic  (latitude  and  longitude)  system. 

For  purposes  of  this  discussion  the  selection  of  the  reference  ellipsoid  for 
this  system  is  unimportant.  The  advantages  to  the  geographic  system  are 
that  every  point  on  the  system  has  a  single  unique  set  of  coordinates,  so 
that  one  does  not  have  the  problem  of  crossing  grid  zones  which  is  so 
prevalent  on  systems  such  as  the  UTM  system.  Also,  the  coordinates  are 
readily  convertible  to  local  tangent.  There  is  one  problem,  however,  which 
must  be  addressed.  This  is  the  problem  of  the  changing  scale  of  the  system 
with  latitude,  which  dictates  that  the  data  points,  if  they  are  to  be  evenly 
spaced  in  terms  of  distance  on  the  ground,  cannot  be  evenly  spaced  in 
geographic  coordinates.  Carried  one  step  further,  it  also  indicates  that 
the  size  of  geounits,  as  defined  in  units  of  latitude  and  longitude,  will 
vary  with  latitude. 

Suppose  that  the  system  is  defined  such  that  the  total  data 
base  area  is  divided  into  bands  in  the  latitude  direction,  each  band 
encompassing  a  distance  of  71  kilometers.  These  bands  can  actually  take 
equal  increments  of  latitude,  since  the  value  of  a  degree  of  latitude  in 
terms  of  ground  distance  various  very  little  over  the  latitudes  of  F.urope. 
Within  each  band,  the  size  of  the  geounit  in  longitude  is  selected  such  that 
the  extent  of  the  individual  geounits  at  the  maximum  latitude  of  the  band 
is  71  kilometers.  A  plot  of  the  system  in  terms  of  geographic  coordinates  1 
shown  below. 


Of  course,  the  divisions  within  the  various  geounits  would  vary  in  size 
in  units  of  latitude  and  longitude  so  that  the  actual  spacing  for  the 
geounlt  is  50  meters  minimum,  but  this  would  be  no  severe  handicap,  as 
the  spacing  could  be  recorded  at  the  beginning  of  the  geounit  record, 
and  then  it  simply  becomes  a  multiplier  when  stepping  through  the  geounit. 
Indexing  of  the  geounits  would  be  simple  because  the  extent  of  each  geounit 
would  be  known  given  the  latitude  band,  and  the  longitude  of  the  central 
meridian  would  be  known.  Therefore,  given  the  latitude  and  longitude  of 
a  target,  the  relevant  geounits  could  be  ascertained  rapidly,  and  the  disc 
location  of  these  geounits  could  then  be  looked  up  in  the  appropriate  index 
to  the  geounits  on  the  discs  to  determine  which  disc  needed  to  be  mounted. 

It  will  also  be  assumed  that,  for  purposes  of  this  study,  all 
data  is  ordered  along  lines  of  constant  latitude,  rather  than  along  lines 
of  constant  longitude.  It  is  realized  that  the  current  terrain  elevation 
data  base  is  ordered  along  lines  of  longitude,  and  such  an  ordering  would 
certainly  be  acceptable  and  would  change  nothing  in  the  results  to  follow 
except  for  the  detailed  algorithms,  but  the  ordering  along  lines  of  constant 
latitude  seemed  more  natural  to  the  authors,  and  thus  was  used. 

It  will  also  be  assumed  that  the  run  length  encoded  compression 
scheme  for  the  planimetrlc  data  which  was  suggested  by  Goodyear  Aerospace 
Corporation  will  be  used  for  storing  the  planimctric  data  in  the  P-11  data 
base.  There  may  be  other  possible  methods,  hut  this  works  within  the  disc 
space  and  retrival  time  requirements,  and  therefore  will  he  assumed. 


ASSUME  DATA  ORGANIZATION  ALONG  SCAN  LINES 
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CON S 1 1) K  HAT  ION  IN  DATA  STORAGE 


DLMS  PLAN  I METRIC  DATA  BASE  HAS  INFORMATION  AT  25M 
RESOLUTION.  REQUIREMENT  FOR  PERSHING  II  IS  SOM. 
THEREFORE  STEP  1  IN  DATA  COMPACTION  IS  TO  PROCESS 
DLMS  DATA  TO  50M  RESOLUTION. 

STEP  II  IS  TO  CONVERT  DLMS  DATA  TO  RASTER  FORM  AND 
RUN  I.KNCTH  ENCODE.  STUDIES  INDICATE  12  TO  1 
COMPRESSION.  THAT  IS,  1  32  BIT  DATA  WORD  PER  12 
SOM  PIXELS. 

ASSUME  USE  OF  CDC  MODEL  640  MOVING  HEAD  DISK 
DRIVE  WITH  4K  DATA  BUFFER. 

STDS  FAST  CHANNEL  HAS  A  DATA  TRANSFER  RATE  OF 
2 SO, 000  16  BIT  WORDS/SECOND. 


CEO  UNIT  -  1420  X  1420  SOM  PIXELS. 

12:1  COMPRESSION  ACHIEVED  QNI Y  IN  DIRECTION  OF  SCAN. 

THEREFORE  ON  THE  AVERAGE  W0  X  1420  >  168.033  32  BIT 

12 

WORDS  PER  CEO  UNIT  OR  672,132  BYTES /CEO  UNIT. 

ASSUME  ELEVATIONS  IN  ABSOLUTE  (?  1 2  BITS/PIXEL  (SM 
RESOLUTION  GIVE  10240M  RANGE.)  EACH  GEO  UNIT 
REQUIRES  711  X  711  X  12  BITS  FOR  TOP 0 
INFO  -  7S8.282  BYTES/GEO  UNIT  THEREFORE: 

TOTAL /CEO  UNIT  -  1.5  X  10^  BYTES 


It  can  easllv  be  shown  that  the  optimum  amount  of  non-redundant 
data  on  a  disk,  assuming  a  certain  fringe  area  to  insure  that  anv  target 
can  be  contained  on  a  single  disk,  is  optimum  if  the  number  of  geounits  or 
non-reduntent  information  on  the  disk  is  an  even  square,  and  the  geounits 
represent  a  square  on  the  ground.  This  is  easily  seen. 
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and  e. 


Although  the  CDC  disc  unit  has  a  maximum  storage  of  80 
megabytes,  only  about  60  megabytes  are  useable  for  data.  Thus  there 
is  a  storage  capability  of  about  forty  geounits  per  disk  pack,  assuming 
that  the  disc  is  formatted  with  five  sectors  per  track. 

However,  problems  occur  when  squares  are  required  for  the 
data  stored  on  each  disc.  As  was  seen,  a  single  disc  will  hold  approximately 
AO  geounits,  Including  overlap.  This  would  allow  only  twenty  five  non- 
redundant  geounits  to  be  stored  per  disc,  assuming  that  each  disc  contained 
a  square  area  of  data.  The  real  problem  arises  because,  as  will  be  seen, 
the  run  length  encoding  scheme  is  not  absolute,  and  therefore  there  is  no 
way  to  predict  a-prlori  what  the  compression  effect  will  be.  Thus,  it  might 
he  possible  on  several  occasslons  to  arrive  at  an  area  in  which  only  sixteen 
non-redundant  geounits  of  information  would  fit  on  a  disc,  which  would  confuse 
both  the  book  keeping  for  the  disc  library,  and  also  waste  considerable  area 
on  the  disc. 


Rather  than  take  that  approach,  suppose  that  one  were  to  use 
a  disc  to  store  a  tier  of  three  goounit  extent  in  latitude,  and  as  much 
as  could  he  handled  in  longitude.  For  the  square  rase,  one  would  get 
twenty-five  non-redundant  geounits  per  disc  on  the  average.  For  this  case, 
one  would  get  40/O+1)  -1  or  9  new  columns  of  geounits,  for  a  total  of  27 
non-redundant  geounits  per  disc.  In  addition,  should  the  compression 
factor  drop,  one  could  easily  store  one  less  column  of  three  geounits  on  the 
disc  which  would  leave  a  maximum  of  wasted  space  of  about  ten  percent  on  that 
one  disc,  and  the  overall  block  nature  of  the  data  base  would  remain  unchanged. 
Indexing  would  he  simple,  because  each  disc  would  contain  geounlts  along  a 
hand  of  latitude  three  geounits  wide. 

It  could  be  argued  that  a  band  four  geounits  wide  would  be 
slightly  more  efficient  (a  single  disc  would  hold  28  new  geounits)  but 
the  cost  of  having  to  stop  one  column  short  i..  the  case  of  low  compression 
would  be  increased. 
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Also,  one  should  note  that  the  nature  of  the  storage  scheme 
defined  above  also  allows  significantly  more  than  twenty-seven  non- 
redundant  geounits  to  be  stored  per  disc  in  the  case  of  areas  of  sparse 
planimetric  detail  which  admit  very  large  compression  factors. 

DISC  TRANSFER  TIMES 

PLANIMETRY 

.  1420  PIXELS/SCAN  LINE  _  EFFECTIVE  PIXELS 

12  AVE  COMPRESSION  FACTOR  '  1  SCAN  LINE 

.  120  FEATURE  WORDS  -  240  16  BIT  WORDS 

•  1956  WORDS/SECTOR  _  SCAN  LINES 

240  WORDS/SCAN  LINE  "  8,15  SECTOR 

.  USE  A  TABLE  AT  THE  BEGINNING  OF  EACH  GEO  UNIT  TO  STORE  THE 

BEGINNING  AND  ENDING  LATITUDE  FOR  THE  DATA  WORDS  IN  EACH 
20K  BUFFER  LOAD. 

.  FROM  TARGET  LATITUDE  AND  LOGITUDE: 

1)  COMPUTE  GEO  UNITS  NEEDED 

2)  READ  TABLES 

3)  COMPUTE  BUFFER  LOADS  TO  READ 

4)  READ  SECTORS  TO  FILL  COMPUTER  CORE  BUFFER 

.  DATA  TRANSFER  RATE: 

ASSUME  5  SECTORS /TRACK 
1956  WORDS /SECTOR 

READ  TIME  FROM  DISK  TO  COMPUTER 


a) 

AVERAGE  ACCESS  TIME 

-  30MS 

b) 

AVERAGE  LATENCY  TIME 

-  8.33MS 

c) 

READ  TO  BUFFER  AT 

1.66  ;; S /WORD 

-  3.25MS 

d) 

TRANSFER  TIME  AT 

4  jjS/WORD 

-  7.82MS 

e) 

TOTAL  TRANSFER 

TIME  PER  SECTOR 

49.40MS 

However,  if  we  assume  that  one  writes  an  entire  core  buffer  in  a  somewhat 
contiguous  manner  on  disc,  a  conservative  estimate  might  be  that  there 
would  be  a  30ms  access  time  for  the  first  read,  and  about  5ms  on  the 
average  for  the  reads  after  that.  There  arc  about  five  reads  for  a  twenty 
buffer  of  information  (twenty  K  bytes),  which  would  take  about  147ms  to 
complete  under  the  above  assumptions.  Because  it  will  be  needed  later, 
the  total  time  to  transfer  thirty-two  K  bytes  would  be  approximately  220ms. 
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ORGAN 1ZATIOX  KOR  PROCESSING  DATA 


ASSUMPTIONS 

1.  We  go  right  from  P-11  data  base  to  radial  data  base  -  the 
intermediate  raster  was  used  for  convenience  in  polygon 
to  raster  conversion.  According  to  ETL  personnel  it  is 
not  really  needed. 

2.  The  data  in  the  geouni ts  are  ordered  along  rows  of  constant 
latitude.  Run  length  coding  obviously  works  in  either  lat. 
or  long. 

3.  There  is  a  30  byte  buffer  available  to  generate  1/8  of  an 
entire  radial  scene  simultaneously  (without  having  to  output 
partial  results  to  disc)  1/8  scene  is  30000  bytes.  This 
buffer  is  not  double  buffered. 

4.  There  are  2  -  20K  buffers  for  double  buffering  input  data 
from  the  P-II  data  base.  By  use  of  the  memory  mapper,  and 
the  data  channels  In  the  PPP  11/70,  only  one  of  these  (the 
one  being  used  in  conputat ions)  need  to  be  the  user  area 
at  one  time.  There  is  b4K  -  bOK  or  14K  left  for  user  code 
and  scratch  storage. 


SEQl'ENCF  IN  DATA  PROCESSING 


The  basic  sequence  is  to  complete  1/8  of  a  scene  at  a  time. 
The  1/8  figure  is  chosen  as  a  balance  between  buffer  size  and  number  of 
passes  through  the  data  base,  and  ts  near  optimum  for  the  problem  at  hand. 


The  process  begins  bv  reading  in  a  20K  buffer  of  planimetric 
data  from  geounit  A.  A  segment,  assuming  a  compaction  ratio  of  12,  covers 
20000/473  or  42  lines  or  2.1  km. 

2. 1- 

All  planimetric  Information  is  extracted  and  placed  in  the  output,  for  the 
area  covered  bv  I.  The  area  processed  first  is  denoted  by  the  red  band  in 
the  drawing.  The  mathematics  involved  will  be  discussed  later,  for  only 
the  disc  transfers  will  be  studied. 
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Sole  that  the  output  scene  covers  several  data  base  units 
Nov,  all  the  data  base  units  cover  essentially  the  same  area  on  the 
ground,  and  have  the  same  number  of  pixels.  Let  us  look  at  the  total 
reads  Involved.  See  table  on  following  page. 

Nov,  there  are  4  scaurs  with  radii  of  35.5,  19.75,  8.875 
and  A. 4375  km  respectively. 

Thus,  the  total  vertical  extent  (records)  to  be  lead  in  t 
worst  case  is: 

8.828  (35.5  ♦  17.75  ♦  8.875  ♦  4.4375)  - 
8.828  (66.5675)  -  587 

say  600  km. 

A  20K  buffer  of  p  lan  ins- 1  r  lc  data  coven.2.1  km,  so  there 

are  286  reads  of  planlmetric  data.  A  20K  buffer  of  t opo  data  rovers 
7  1 000 

20000/—  "■  ♦  1  X  1.5  rows  X  100  meter/row  *  1.877  km.  So  there 

1  vHJ 

are  319  reads  of  topo  data.  Karh  read  takes  147ms  or  total  disc 
time  for  input  is  147  X  (319  ♦  286)  ■  R9  seconds.  Output  of  the 
four  completed  scenes  would  take  4  X  8  X  .220ms  •  7.04  seconds. 

Total  disc  time  96  seconds. 

Now  for  the  computations.  If  the  disc  1/0  is  not  double 
buffered,  the  computation  time  adds  to  the  output  time,  which  is  the 
pessimistic  approach. 

Look  at  the  case  of  a  single  segment,  and  a  single  buffer 
load,  as  represented  on  the  next  page. 


FIGURE  2 

The  idea  is  to  fill  in  as  many  pixels  of  output  as  is  possible 
from  this  buffer.  There  are  several  phases  to  the  ccnaputat  ion.  First  of 
all,  the  point  in  the  output  must  be  converged  to  geographies  so  that  its 
position  in  the  input  can  be  determined.  Secondly,  the  value  at  the  input 
must  be  found,  and  third,  it  must  be  masked  Into  the  output. 

Running  some  simple  numbers  savs  that  to  do  this  by  brute  force 
methods  takes  manv  minutes.  Therefore,  we  must  get  smart. 

Let’s  look  at  the  problem  in  pieces.  First  of  all,  check  the 
problem  of  conversion  from  local  tangent  to  geographies.  Suppose  as  a 
preliminary  exercise  when  we  began  a  scene  that  he  were  to  compute  a  grid 
of  local  tangent  to  geographic  values.  Some  preliminary  computations  show 
that,  to  better  than  3  meter  accuracy  a  grid  of  6  X  6  stations  would  easily 
cover  a  quarter  of  the  scene.  Thus  36  X  3  or  96  words  of  storage  would  be 
needed  for  this  table.  Its  computation  would  entail  2  to  3  seconds  4  times 
or  a  total  of  12  seconds  during  the  scene  generation. 
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Clven  this  table,  one  could  linearly  interpolate  for  latitude 
and  longitude.  A  bilinear  interpolation  takes  2  divides,  a  multiply  and 
and  an  add  to  find  the  start  point  and  3  more  adds  to  address  the  other 
points.  The  actual  computations  take  the  form. 


or  for  lat,  long  A  ht. 

Time  each 

INDEXING 

2  Div  (Integer) 

10.55  Us 

1  Mult  (Integer) 

5.30  Us 

12  Adds 

2.30  us 

COEFFICIENTS 

4  Subtracted 

2.30  us 

4  Stores 

1.00  us 

COMPUTATION 

39  Loads 

1 .00  us 

18  F  Hq.  Mults. 

2.5  us 

9  F  Hq.  Adds 

1  us 

9  F  Hq.  Divides 

3. 5  us 

3  Stores 

1  us 

Which  is  still  obviously  too  much  work  to  do  each  time.  But, 
we  will  be  going  along  straight  lines  in  the  output.  Thus,  by  computing  a 
point  every  50  or  so  points  by  the  above  method,  one  can  reduce  the  process 
of  moving  from  point  to  point  to  the  adding  of  an  increment  to  three  values 
or  6  loads,  '  I  adds  and  3  stores  gets  the  new  point  lat,  long  A  ht.  offset 

Assume,  on  the  average,  only  one  point  in  20  will  need  rigorous 
computation,  whith  the  rest  using  simple  increment  addition.  (For  the  small 
scenes,  the  compression  could  be  even  higher,  but  in  large  scenes,  the  bands 
of  2.1  km  extent  cover  less  than  20  points  along  a  scan,  so  twenty  should 
be  a  good  number  on  the  average). 


So  the  operations  to  compute  20  latitude  &  longitude  Is 

2  Int.  Dlv. 

1  Int.  Mult. 

9  F  add 
71  adds 
153  loads 
64  stores 
18  F  mu 1 1  s 

9  F  divides 

or  an  average  of  492/20  or  25  us  per  point. 

We  now  have  the  point  In  geographies.  At  this  point,  the 
problem  splits  Into  whether  one  Is  working  topo  or  planimetry.  First, 
however,  one  should  look  at  the  problem  of  computing  the  desired  local 
tangent  position  of  each  output  point.  At  first  glance.  It  seems  simple, 
because  It  Is  simply  moving  down  a  radial  line.  However,  If  the  sines  and 
cosines  are  recomputed  for  each  20k  buffer  of  information  which  is  read 
in  during  the  process  of  generation  an  eighth  of  a  scene,  the  computation 
t i me  could  be  considerable.  The  solution  to  the  problem  is  to  store  a 
table  of  the  sines  and  cosines  of  the  various  radial  scan  lines  for  the 
scene  currently  being  worked  on  in  core,  so  that  these  can  be  looked  up 
readily  to  determine  the  steps  to  take  in  moving  dew  the  scan,  and  also 
in  computing  such  things  as  the  first  point  on  each  scan  which  falls  in  the 
current  buffer  area. 

Because  these  sine  and  cosine  computations  take  a  considerable 
amount  of  time,  it  would  be  adviseable  to  generate  the  same  octant  of  all 
four  scenes  sequentially,  preserving  the  table  from  one  to  the  next.  Thus, 
the  table  will  have  to  be  generated  onlv  eight  times,  giving  a  total  of 
500  sines  and  500  cosines  to  be  computed.  This  process  should  take  less 
than  two  seconds  total  to  accomplish. 

There  is  also  the  problem  of  determining  where  to  start  each 
sweep  line  generation  when  each  data  buffer  is  in  core.  For  every  buffer 
read,  there  will  be  125  lines  to  determine  the  start  position  on.  This 
will  require  a  divide  and  a  conversion  to  integer.  There  are  605  buffer 
reads,  so  there  will  be  125  X  605  divides  and  conversion  to  Integer,  which 
will  take  approximately  1  second  to  perform.  Thus,  using  the  above  scheme, 
the  problem  of  determining  the  starting  position  on  each  scan  line,  and  the 
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constants  to  use  In  stepping  down  the  scan  line  will  take  approximately  1 
second  total  time  for  the  generation  of  four  scenes. 

Now  let's  look  at  the  topographic  problem.  For  each  point 
in  the  output,  one  needs  to 

1.  Compute  the  latitude  and  longitude 

2.  Do  a  bilinear  interpolation  for  elevation 

3.  Add  the  offset 

A.  Store 

taking  these  steps  individually,  we  see  that  (1)  has  already  been  found 
to  take  25  us.  Because  (1)  will  be  done  for  some  points  which  will  not 
prove  to  be  in  the  actual  buffer  area,  because  of  the  searching  algorithm 
described  above,  one  could  assume  a  10Z  waste,  or  27.5  Us  per  point  on 
the  average. 


The  bilinear  interpolation  is  the  same  as  before,  but  is 
only  in  elevation,  and  so  takes 


IJ 


| 

I 


l! 


IJ 


0 


INDEXING 

COEFFICIENTS 

COMPUTATIONS 

or  a  total  of 

or  142  u«  per  point. 

Adding  the  offset  is 
a  masking  operation,  which  at  most 
an  add,  or  5  Us  per  point. 


2 

Int  div 

1 

Mult 

4 

Adds 

4 

Subtracts 

(storage  in  registers 

f> 

F  mu  1 1  s 

12 

loads 

4 

divs 

3 

F  adds 

4 

shifts 

3 

F  divides 

4 

masks 

3 

F  divides 

6 

I  div 

6 

mu  Its 

1 

I  mult 

8 

1  adds 

3 

F  adds 

4 

shifts 

12 

loads 

4 

masks 

one  add  or  2  us.  Storing  consists  of 
could  be  2  loads,  a  mask,  a  shift  and 
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One  thus  arrives  at  an  estimate  of  149  ps  per  point  for 
elevation  determination,  exclusive  of  latitude  6  longitude  determination. 

For  planimetry,  the  problem  is  somewhat  different.  The 
computation  of  latitude  and  longitude  is  the  same,  but  the  major  problem 
is  not  interpolation  (the  nearest  point  values  must  be  used)  but 
unpacking  the  run  length  encoded  data  if  one  were  to  read  through  t  he 
buffer  from  the  start  to  find  each  point,  the  problem  is  intrackable. 

Suppose,  however,  that  for  each  row  of  data  one  were  to  keep  the  4  variables! 

(Min  Long,  Max  Long,  Attribute,  location)  stored  in  a  core  buffer. 

Determining  the  row  of  the  point  is  simple.  By  the  process  described  above, 
the  scans  tend  to  move  monotonical ly  in  Longitude,  therefore,  if  the  point 
does  not  lie  in  the  current  section  for  that  row,  one  must  move  in  the 
appropriate  direction  from  the  location  in  the  reference  stack,  and  update 
the  reference  stack. 

The  point  is  that  the  entire  buffer  must  be  traversed  once  to 
form  the  beginnings  of  rows,  and  at  most  once  again  to  handle  the  monotonic 
change.  The  first  traverse  requires  that  each  of  5000  entries  be  read,  and 
the  2nd  byte  compared  to  0.  This  involves  5000  loads,  5000  adds,  and  5000 
compares.  For  the  average  of  42  rows,  for  the  first  record  one  must  do  a 
load,  2  masks,  6  shifts,  5  adds,  and  4  stores.  (Assume  cache  memory  used 
for  this  critical  phase). 

This  initial  set  up  the  tables 


5210 

1  adds 

.3 

US 

5042 

Loads 

1 

p  s 

5000 

compares 

.3 

ws 

84 

masks 

.3 

IIS 

84 

shifts 

1 

VJS 

164 

stores 

1 

US 

To  traverse  once  takes 

5000*  1  1  adds 

2  compares 
1  mask 
4  loads 
8  stores 


5000  1  adds  (INT) 
10000  compares  »3 
or  5000  masks  « 3 

20000  loads  1 

40000  stores  1 


The  previous  page  took  care  of  all  changes  in  the  table  for  a  given  record, 
or  84.4  ms/record. 


Now,  for  each  point,  one  has  only  to  select  the  row,  which 
takes  an  add  and  a  divide,  a  multiply  and  add  to  get  the  address  of  2 
loads,  and  two  compares.  Storage  takes  3  masks,  3  shifts,  3  adds,  and 
3  stores.  This  gives  a  total  per  point  of 

6  I  adds 
1  1  divide 

1  I  multiply 

2  loads 

3  masks 
3  shifts 
3  stores 


The  above  gets  done  for  every  point,  and  takes  40,65  Us  per 

point . 


Now  one  can  add  up  the  operations,  assuming  no  parallel 

processing. 


Total  disc  read  time 

derivation  of  4  Lat.  long  grids 

Computation  of  point  Lats  6  Longs 
(twice  for  each  pt.  with  101  waste) 

Computation  of  starting  radii  for  buffers 

Elevation  interpolation 

Setting  up  buffers  for  planimetrv 
(284  buffers  X  84378) 

Moving  through  on  planimetry 

Setting  up  sire  4  cosine  tables 


96  secs. 

12  secs. 

(50  us  X  240000)  +  10J 
13.2  secs. 

1.2  secs. 

(149  us  X  240000) 

35.76  secs. 

23.96  secs. 

9.75  secs. 

,  l 

3  secs. 

- - -  ■- 

194.87  secs. 


CONCLUSION 


The  above?  discussion  has  been  carried  out  in  considerable 
detail.  It  is  believed  that  every  major  contribution  to  the  total 
processing  time  has  been  taken  into  account.  There  is  one  major  area, 
however,  which  has  not  been  accounted  for,  and  which  cannot  be  accounted 
for  prior  to  writing  the  actual  software  and  running  benchmarks.  This 
is  the  area  of  program  control  and  logical  overhead. 

For  the  above  reasons,  it  would  be  wise  to  place  roughly 
a  factor  of  three  safety  factor  on  the  above  numbers.  With  double 
bufferring  of  only  the  input,  this  should  still  get  the  total  computational 
time  to  well  under  ten  minutes. 

The  above  estimates  assumed  that  the  software  was  being  written 
by  a  competent  programmer  who  was  striving  to  write  extremely  efficient  code. 
This  times  could  easily  go  up  by  an  order  of  magnitude  if  the  same  type  of 
careful  analysis  and  procedures  which  were  followed  in  the  above  analysis 
are  not  followed  in  the  actual  programming. 


